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MAILBOX NAMES FOR 
COMMON SERVICES, ROLES AND FUNCTIONS 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
ABSTRACT 


This specification enumerates and describes Internet mail addresses 
(mailbox name @ host reference) to be used when contacting personnel 
at an organization. Mailbox names are provided for both operations 
and business functions. Additional mailbox names and aliases are not 
prohibited, but organizations which support email exchanges with the 
Internet are encouraged to support AT LEAST each mailbox name for 
which the associated function exists within the organization. 


1. RATIONALE AND SCOPE 


Various Internet documents have specified mailbox names to be used 
when reaching the operators of the new service; for example, [RFC822 
6.3, C.6] requires the presence of a <POSTMASTER@domain> mailbox name 
on all hosts that have an SMTP server. Other protocols have defacto 
standards for well known mailbox names, such as <USENET@domain> for 
NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]). 
Defacto standards also exist for well known mailbox names which have 
nothing to do with a particular protocol, e.g., <ABUSE@domain> and 
<TROUBLE@domain>. 


The purpose of this memo is to aggregate and specify the basic set of 
mailbox names which organizations need to support. Most 
organizations do not need to support the full set of mailbox names 
defined here, since not every organization will implement the all of 
the associated services. However, if a given service is offerred, 
then the associated mailbox name(es) must be supported, resulting in 
delivery to a recipient appropriate for the referenced service or 
role. 
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If a host is not configured to accept mail directly, but it 
implements a service for which this specification defines a mailbox 
name, that host must have an MX RR set (see [RFC974]) and the mail 
exchangers specified by this RR set must recognize the referenced 
host’s domain name as "local" for the purpose of accepting mail bound 
for the defined mailbox name. Note that this is true even if the 
advertised domain name is not the same as the host’s domain name; for 
example, if an NNTP server’s host name is DATA.RAMONA.VIX.COM yet it 
advertises the domain name VIX.COM in its "Path:" headers, then mail 
must be deliverable to both <USENET@VIX.COM> and 
<USENET@DATA.RAMONA.VIX.COM>, even though these addresses might be 
delivered to different final destinations. 


The scope of a well known mailbox name is its domain name. Servers 
accepting mail on behalf of a domain must accept and correctly 
process mailbox names for that domain, even if the server, itself, 


does not support the associated service. So, for example, if an NNTP 
server advertises the organization’s top level domain in "Path:" 
headers (see [RFC977]) the mail exchangers for that top level domain 


must accept mail to <USENET@domain> even if the mail exchanger hosts 
do not, themselves, serve the NNTP protocol. 


2. INVARIANTS 


For well known names that are not related to specific protocols, only 
the organization’s top level domain name are required to be valid. 
For example, if an Internet service provider’s domain name is 
COMPANY.COM, then the <ABUSE@COMPANY.COM> address must be valid and 
supported, even though the customers whose activity generates 
complaints use hosts with more specific domain names like 
SHELL1.COMPANY.COM. Note, however, that it is valid and encouraged 
to support mailbox names for sub-domains, as appropriate. 


Mailbox names must be recognized independent of character case. For 
example, POSTMASTER, postmaster, Postmaster, PostMaster, and even 
PoStMaStEr are to be treated the same, with delivery to the same 
mailbox. 


Implementations of these well known names need to take account of the 
expectations of the senders who will use them. Sending back an 
automatic mail acknowledgement is usually helpful (though we suggest 
caution against the possibility of "duelling mail robots" and the 
resulting mail loops). 
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3.  BUSINESS-RELATED MAILBOX NAMES 


These names are related to an organization’s line-of-business 
activities. The INFO name is often tied to an autoresponder, with a 
range of standard files available. 


MATLBOX AREA USAGE 

INFO Marketing Packaged information about the 
organization, products, and/or 
services, as appropriate 


MARKETING Marketing Product marketing and 
marketing communications 

SALES Sales Product purchase information 

SUPPORT Customer Service Problems with product or 
service 


4. NETWORK OPERATIONS MAILBOX NAMES 


Operations addresses are intended to provide recourse for customers, 
providers and others who are experiencing difficulties with the 
organization’s Internet service. 


MATLBOX AREA USAGE 

ABUSE Customer Relations Inappropriate public behaviour 
NOC Network Operations Network infrastructure 
SECURITY Network Security Security bulletins or queries 


5. SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES 


For major Internet protocol services, there is a mailbox defined for 
receiving queries and reports. (Synonyms are included, here, due to 
their extensive installed base.) 


MAILBOX SERVICE SPECIFICATIONS 
POSTMASTER SMTP [RFC821], [RFC822] 
HOSTMASTER DNS [RFC1033-RFC1035] 
USENET NNTP [RFC977] 

NEWS NNTP Synonym for USENET 
WEBMASTER HELEP. [RFC 2068] 

Www HTTP Synonym for WEBMASTER 
UUCP UUCP [RFC976] 

FTP FTP [RFC959] 
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6. 


MAILING LIST ADMINISTRATION MAILBOX 


Mailing lists have an administrative mailbox name to which add/drop 
requests and other meta-queries can be sent. 


For a mailing list whose submission mailbox name is: 

<LIST@DOMAIN> 
there MUST be the administrative mailbox name: 

<LIST-REQUEST@DOMAIN> 
Distribution List management software, such as MajorDomo and 
Listserv, also have a single mailbox name associated with the 
software on that system -- usually the name of the software -- rather 
than a particular list on that system. Use of such mailbox names 


requires participants to know the type of list software employed at 
the site. This is problematic. Consequently: 


LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED, 
INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE 
MAILBOX NAMES. 


DOMAIN NAME SERVICE ADMINISTRATION MAILBOX 


In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of 
Authority record (SOA RR) has a field for specifying the mailbox name 
of the zone’s administrator. 


This field must be a simple word without metacharacters (such as "%" 
or "!" or "::"), and a mail alias should be used on the relevant mail 
exchanger hosts to direct zone administration mail to the appropriate 
mailbox. 


For simplicity and regularity, it is strongly recommended that the 
well known mailbox name HOSTMASTER always be used 
<HOSTMASTER@domain>. 
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8. AUTONOMOUS SYSTEM MAILBOX 


Several Internet registries implement mailing lists for Autonomous 
System contacts. So, for example, mail sent to <AS3557@RA.NET> will 
at the time of this writing reach the technical contact for 
Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and 
[RFC1656]). 


Not all Autonomous Systems are registered with all registries, 
however, and so undeliverable mailbox names under this scheme should 
be treated as an inconvenience rather than as an error or a standards 
violation. 


9. SECURITY CONSIDERATIONS 
Denial of service attacks (flooding a mailbox with junk) will be 
easier after this document becomes a standard, since more systems 
will support the same set of mailbox names. 
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